Modern software development often involves asynchronous programming. Multi-core central processing units (CPUs), networks, distributed systems, sensors, and so on all bring about asynchrony. This corresponds to an increased level of event-based programming, where each of the asynchronous entities interacts with others by raising events. For example, mouse movements generate graphical user interface (GUI) events that encapsulate the cursor's position; the completion of an XmlHttpRequest call generates an event signaling that results are available; and the publication of a blog post produces an event that notifies interested parties that new content is available. Typically, these events are not correlated. For example, a GUI event corresponding to moving the mouse is raised independently of an event signaling the completion of an asynchronous XmlHttpRequest call.
Testing event-based systems involves verifying that the program behaves as expected as events from uncorrelated sources occur. This is a hard problem as verifying all possible permutations exhibits combinatorial explosion. Consequently, testers are increasingly relying on fuzz testing, or fuzzing, which involves randomly generating events from outside of the application under test, and verifying whether the application responds as specified. Fuzz testing can provide much broader coverage for a given amount of effort and is especially favored when budgets and/or time are short.
Fuzz testing is difficult to introduce to some applications. For example, the application may not provide easy entry points for hooking event sources and sinks. Other times it is easy to produce some types of inputs (e.g., calling a registered event handler), but hard to reliably produce sequences of events to test reordered, delayed, duplicate, and/or lost events. Introducing fuzz testing to an application is typically handled differently each time, and each application programmer may repeat work performed many times before to re-implement fuzz testing in a new application.